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INTRODUCTION 


A human factors research and applications program is managed by the Mission 
and Data Operations Directorate (M 6c DOD) at the National Aeronautics and Space 
Administration (NASA) Goddard Space Flight Center (GSFC). The M 6c DOD is 
responsibile for defining, designing, developing, and operating both data processing 
and real-time control systems in support of various NASA satellite missions. By 
virtue of this responsibility, M 6c DOD is concerned with incorporating the rapid and 
revolutionary advances in computer technology into system design cycles. 
Management at GSFC has also become aware that implementing the tools of new 
technology without due consideration of the user may result in lowered acceptance 
and less than optimal performance by the user. As a result, there has been an 
increased interest in the field of human factors (HF) which defines the limits and 
capabilities of the human as the dynamic component of systems operations. 

The M 6c DOD has formed a Human Factors Group whose objectives are to 
provide research and development as well as applied human factors analysis for 
GSFC projects. This analysis includes recommendations for the application of 
human factors principles in the design of human-machine interfaces. Because the 
Human Factors Group was formed only recently, effective policy is still under 
development. One specific concern has been the formulation of a methodology to be 
used when human factors analysts interact with Goddard projects. This framework 
would facilitate an effective, informative pattern of interaction between the Human 
Factors Group and projects or facilities requesting assistance. 

Recently, human factors analysis has been applied on an ad hoc basis to the 
Earth Radiation Budget Satellite (ERBS) mission operations room and the Mission 
Planning Terminal (MPT) software design project. The methodology proposed in this 
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paper is based on insights resulting from experience with these two real-time support 
applications. Generally, these applications maintain the health and safety of 
spacecraft, provide computer and communications capabilities, and optimize data 
collection from scheduled spacecraft contacts as they occur. 

The methodology is addressed to human factors analysts, project developers, 
and management. It is designed to assist in the process of coordinating the human 
factors analysis with the life cycle of system development, selecting areas for 
analysis, and selecting appropriate human factors tools. The document assumes some 
familiarity with human factors concepts. References are provided for further 
information on the details of specific theories and procedures. 
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BRIEF GUIDE TO METHODOLOGY 

I. Establish a working relationship with the project; 
o Organize human factors analysis team; 

o HFG designates analyst(s) and analyst coordinator. 

o Project designates mission coordinator. 

o Develop a contractual aggreement; 

o Project states interest in receiving human factors support. 

o Human Factors Group (HFG) provides project with 
capabilities list. 

o Both project and HFG come to mutual agreement on goals 
and directions of human factors analysis. 

o Contract is drafted and signed. 

o Determine frequency of communications and required levels of 
feedback. 

o Meet at least twice monthly, 
o Place analysts on project mailing list, 
o Attend formal and informal design reviews, 
o Review progress periodically. 

II. Orient human factors analysts to the project: 
o Observe existing system. 

o Review project documentation, 
o Develop and rank human factors criteria. 

III. Identify the current stage of system development and conduct 
human factors analysis accordingly. Stages of system development 
identified below are based on DeGreene’s (1970b) terminology. 

Human factors analysts will apply selected techniques at each 
stage, depending on the time and personnel allotted to the task. 

o Conceptual or planning stage; 

o Review documentation on existing or antecedent system. 
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o Begin identifying behavioral and informational 

requirements. 

o Begin identifying design criteria, e.g., error tolerance, 
o , Definition stage; 

o Refine design criteria. Conduct formal sessions to rank 
criteria or to evaluate rankings if they have been 
previously determined. 

o Perform tradeoffs analyses to determine preliminary 

allocation of functions. 

o Analyze tasks, functions, and jobs to evaluate preliminary 
allocation of functions and overall job design. 

o Evaluate alternative subsystem components (e.g., 

interaction devices, display formats, command language, 
and workstation layout) for congruence with human 
requirements. Use empirical methods and other 

appropriate human factors* tr<ols. 

o Conduct studies of staffing and training requirements. 

o Evaluate external and internal documentation on the basis 
of criteria such as continuity, logic, and clarity. 

o If time and staff qualifications allow, use simulation 
techniques or mathematical modelling to refine definitions 
of human requirements, 

o Design and production stage*. 

o If human factors support begins at this point, identify 
human factors problems, areas of flexibility, and design 
constraints. 

o Apply human factors tools, such as existing guidelines, 
expert judgment, and paper mockups, to area(s) for 
analysis. Perform task analysis to assess workload 
allocation. 

o Assess alternatives on the basis of ranked criteria, 
o Operational stage: 

o Conduct field evaluations of operational system. 

o Identify unanticipated design problems. 
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o Evaluate user rnponse to the system by means of surveys 
and interviews. 

o Evaluate efficiency and effectiveness of maintenance 
procedures. 

o Conduct error analysis on human performance. 

o Evaluate suggested changes for their potential impact on 
the human-machine inferface. 

IV. Document the analysis and make recommendations. 

o Maintain written records and chronology of analytical 
activities. 

o Prepare written reports including recommendations, 
o Make oral presentation using viewgraphs and handouts. 

V. Plan for regular evaluation of human factors considerations 
throughout the life of the system. 

o Schedule an annual review of human-maehine-environmental 
compatibilities. 

o Present recommendations for enhancements to the system. 
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INITIATING AND PLANNING A HUMAN FACTORS ANALYSIS 


OVERVIEW 

Ground rules need to be determined to effect an orderly process of integrating 
the human factors analysis into the design schedule. The initial planning phase of a 
human factors analysis is of particular importance because human factors analysts 
are typically not included on the standard design team. Therefore* the Human 
Factors Group (HFG) and projects requesting human factors support should follow 
specific procedures to ensure the onset of prompt, effective actions. These 
procedures include a statement of project interest, a HFG response in the form of a 
list of areas human factors can impact, and finally, mutual consent to a contract for 
HF work to be undertaken. 


OPGAW'/l^G THE HUMAN FACTORS ANALYSIS TEAM 

Tne Human Factors Group operates under the auspices of Code 500, Mission and 
Data Operations Directorate. Its membership includes NASA personnel, university 
faculty and graduate students, and other GSFC contractors. The human factors 
analysts are independent of specific projects at Goddard yet are responsive to the 
needs of the project to which they are assigned. Graduate student analysts are 
responsible to university faculty who, in turn, function as principle investigators, and 
are responsible to their NASA technical monitors. This organizational structure 
gives the human factors analyst some autonomy from the project. Historically, HF 
analysts have functioned as consultants. This role gives some distance from day to 
day problems and constraints and may yield a new and somewhat more objective 
perspective of the planned system. Because of his/her training, the HF analyst is 
often able to identify issues that may be causing human factors problems. 
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Tlie requesting project should designate a mission coordinator to act as a liaison 
between the HFG and the project. This coordinator attends the monthly HFG 
meetings to report ongoing work and also maintains direct contact with the human 
factors analysts. If there are several HFG analysts, there is a need for 
coordination. It is strongly recommended that one HF person be given the 
responsibility to direct the process of developing human factors recommendations for 
the project (Peterson & Batteriil, 1982). The aim is to develop an integrated team 
approach. 

DOCUMENTING THE PROJECT'S HUMAN FACTORS REQUIREMENTS 

A request for human factors support generally originates with a written or 

verbal statement of interest from the project to Code 502, Data Systems Technology 

Office, a branch of M & DOD. In return, the HFG should provide the project with a 

capabilities list, stating areas where human factors might be effective. This list 

defines the scope of human factors analysis in the GSFC environment where likely 

areas for analysis include the following: 

o hardware selection and design 

o software considerations such as dialogue 

types and display design 

o documentation of operations and procedures 
o workstation design 
o command and control panel design 

After evaluating the capabilities list and deciding on a subset of areas for analysis, 
the project should prepare a written statement of specific goals to be achieved 
through HF interaction. The HFG executive committee and the requesting project 
then determine the feasibility of a joint work relationship. When agreement is 
reached, human factors specialists are assigned to the project. 
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The initial exchange establishes the capabilities of the HFG and determines the 
project's immediate priorities. However, before the analysis begins, the HFG 
analysts and the project managers should mutually agree on the goals and directions 
of human factors analysis and draft a contract to that effect. The contract should 
include the project's priorities for particular areas of analysis. For example, is 
workstation design, documentation, or hardware selection of prime importance? 
How much emphasis should be placed on the remaining areas for analysis? This 
written agreement defines the relationship between the project and the HFG and 
serves as a basis for periodic review of progress. 

PLANNING COMMUNICATIONS AND FEEDBACK 

Early in the formulation of a working relationship, both the project and the 
HFG should establish the desired frequency or regularity of meeting together. 
Previous experience has shown that a failure to establish a regular pattern of 
interaction leads to problems for the analyst. Problems include: 

o a slower start for the analysis 

o inadequate amount of information relayed by the project 
to the analyst 

o failure of HF analysts to keep abreast of changes made by 
the project 

o being unaware of working dynamics of the design team 

o an increased timing problem between generation of 
recommendations and the time when they can be 
incorporated into a design 

To be effective, human factors analysis of a GSFC project requires frequent 
contact between the project and the HF analysts assigned to the project, attendance 
by HF personnel at any important project meetings, and guidelines for written 
communications between HF analysts and project personnel. 
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The HF analysts should meet regularly with the project design team, at least 
twice monthly. At these meetings they will have the opportunity to review progress, 
discuss any new issues, and resolve any problems encountered. These sessions should 
be part of the normal design process. Once the HF analysts have become oriented to 
the project, a regular meeting might be scheduled to rank the criteria used in human 
factors analysis. For example, in a workstation layout, is it more important for the 
commander to be protected, or to allow for ease of interaction among various 
control room personnel? In a software development design, is it more important to 
incorprate an on-line help feature or does the need and cost not justify its inclusion? 

In addition to regular meetings, the analysts should be placed on the project’s 
mailing list. Thus, they will be assured of receiving notice of upcoming meetings and 
copies of revised or newly released documentation. 

Attendance at Design Reviews 

Deadlines for design reviews are set by the development schedule of a system. 
Analysts should request a list of these scheduled dates. These design reviews range 
from informal, spontaneously arranged work sessions to formal design reviews 
planned months in advance. The evaluation of the ERBS workstation layout occurred 
over several informal working group meetings. In contrast, the software developers 
of the MPT project held a formal preliminary design review (PDR) followed by a 
formal critical design review (CDR) three months later. After each of thes^ 
presentations, portions of the MPT development design were frozen and no longer 
amenable to further adjustment. For this reason, it is important for the human 
factors analysts to be aware of design reviews, both formal and informal. 

Attendance at design reviews keeps the analysts abreast of information. 
Human factors analysts should always be notified of, and attend, the formal design 
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reviews and important informal working sessions. Selective attendance is 
recommended at other review sessions depending on their applicability. 

Requirements for Written Communication 

Often the HF analysts will need to provide responses to HF issues raised in a 
design review or in project documentation. Such responses should be in writing. If 
specific design recommendations are given, e.g., display screen configurations, they 
should be based on existing guidelines, established laws of behavior, or previous 
research which is cited in the report. This justification provides the project with 
empirical evidence to support implementation of such recommendations. 

The entire span of written and verbal communication is obviously important. It 
forms the basis of an effective working relationship. Feedback from the project to 
the analysts and vice versa is also important. Periodically, HF analysts and the 
project coordinator should review the initial goals and objectives contained in the 
contract and determine whether they are being satisfactorily met. This periodic 
self-evaluation should include a brief written summary of human factors activity to 
date. 

MANAGEMENT'S ROLE IN PROVIDING SUPPORT 

Management support is vital for successful implementation of any program. 
Human factors, a new concept for most systems at GSFC, is in particular need of 
support during its introductory phase. 

NASA Management 

NASA management should provide ongoing support for human factors because 
the policies of senior management influence project managers, project staff, and 
supporting contractors. The support of project management for a specific human 
factors application is essential. To ensure this support, project management should 
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be included in the development of the HFG/project contract and be a signatory of 
the final document. 

HFG Technical Monitors 

Each contract has a monitor representing Goddard management. Because the 
HF analyst is typically not a Goddard employee, the role of the technical monitor 
includes the following functions: 

o acting as liaison between HF analyst and the project 

o coordinating the scheduling of meetings and onsite 
observations 

o identifying key personnel in projects 

o coordinating follow-up on action items 

o informing analysts of supplementary programs or talks 
presented at Goddard that would benefit analysts 

o being available to act on behalf of the HF analyst if there 
are policy problems with the project 

o following the progress of applied analysis to determine 
whether cooperation is effective 

This support facilitates the smooth integration of human factors recommendations 
into the design process. 
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ORIENTING HUMAN FACTORS ANALYSTS TO THE PROJECT 


OVERVIEW 

Following the initial planning, human factors analysts need to gain a working 
knowledge of the project. Rather than attempting to master specific jobs, analysts 
must acquire a broad, conceptual understanding of the project as a system. 
Attention focuses on mission goals, general procedures, and expectations for human 
performance. Because these expectations may not be documented thoroughly, it is 
the analysts’ responsibility to begin identifying the project’s human requirements. 
Appropriate methods include onsite observation, informal discussions, and review of 
technical documentation. A formal discussion of design criteria is needed to develop 
the ranking of criteria which is used as the basis for analysis. Orientation aids 
analysts in identifying the stage of system development in effect as they begin the 
human factors analysis. 

OBSERVING EXISTING SYSTEMS 

If there is an existing system that is similar to the one being developed, 
observations and informal discussions with operational and supervisory personnel 
contribute enormously to the analysts’ understanding of the project under 
consideration. If the project involves the development of an entirely new system, 
observation of any antecedent system will help analysts conceptualize the functions 
to be performed. In the case of MPT, human factors specialists observed CAIRS, an 
antecedent to the automated system being developed; in the case of the ERBS MOR 
workstation design, observations in the Data Operations Control (DOC) area and 
current MORs provided an understanding of real-time support procedures. 
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At the beginning of observational visits, the goals of the human factors analysis 
should be briefly explained to the operational staff in order to clarify the purposes of 
onsite observation. Once rapport is established with operators and their supervisors, 
it is invaluable to ask questions and raise potential human factors issues. After 
prolonged use of a particular system, operators are acutely aware of the extent to 
which human capabilities and limitations are provided for by that system, and they 
can be extremely helpful in formulating suggestions * and recommendations for 
improvement. Their reactions to preliminary designs and their anecdotal accounts of 
past experiences with other systems are valuable contributions to the assessment of 
the project's human-machine interfaces and other human requirements. 

The MPT and ERBS experiences suggest that observations in more than one 
command and control environment are essential to provide a generalized 
understanding of Goddard operations. Follow-up sessions with project developers 
also contribute immensely to an understanding of the relationships among 
components of the Goddard support network. A sense of interrelatedness is crucial 
to the development of an analytical framework. 

REVIEWING PROJECT DOCUMENTATION 

Additional contributions to a conceptual understanding of the project come 
from a review of technical documentation. Because such documentation typically 
focuses on non-human system requirements, it is the analysts' task to identify the 
human requirements implied or suggested by technical specifications for hardware 
and software. The final report on ERBS MOR workstation design (Stewart, Murphy, 
& Mitchell, 1982) recommends that future project documentation include behavioral 
descriptions of required individual actions and person-to-person interactions. 
Implementation of this recommendation will ensure that the resulting documentation 
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provides valuable information for human factors analyses. Until such time as this 
suggestion is implemented, however, it is the responsibility of the human factors 
analysts to document these requirements. Descriptions of human requirements 
should be included in a preliminary report to the project and the technical monitor. 

DEVELOPING AND RANKING HUMAN FACTORS ANALYSIS CRITERIA 

Human factors analysts need a set of standards or criteria on which to base 
their analysis. To meet this requirement, appropriate human factors criteria should 
be identified in conjunction with the project. During this process, it is important to 
identify criteria which might have been left implicit or unstated by the project 
earlier in the orientation phase. Competing criteria should be identified and ranked 
before analysts attempt to assess the benefits and limitations of any one design. 
This procedure is recommended so that alternative designs can be evaluated against 
the same set of standards. 

The development and ranking of human factors criteria proceeds within the 
context of NASA/GSFC policy and standard procedures. Explicit definition of 
project goals and candid discussion of the human role in the system are required to 
identify project-specific design criteria such as: 

o reduction of human information processing requirements 
o ease of maintaining equipment 
o minimal distraction to the command operator 
o useability of the system 

o smooth traffic patterns 

o * effective and efficient human performance 
o reduction of staffing levels 
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Some of the emerging criteria will be related to each other, as minimal distraction 
to the command operator is related to effective and efficient performance. 
Additionally, some criteria will be stated in more general terms than others. 
Therefore, for purposes of clarity and organization, specific criteria should be listed 
under the appropriate general criteria. To avoid the need for major retrofitting of 
the analysis, the identification of design standards should be as exhaustive as 
possible. The general criteria should be ranked in importance, perhaps by the Delphi 
method of achieving consensus (Cascio, 1978; Huchingson, 1982), This ranking 
procedure can also be applied to the specific criteria listed under each general 
category. (Details on the Delphi method can be found in the later discussion of 
human factors tools, Under Ratings by Experts .) 

The absence of an explicit, prioritized set of criteria can result in the problem 
of shifting criteria described in Stewart et al. (1982), If the project’s standards are 
ambiguous, it will not be possible to provide an effective human factors analysis of 
proposed alternatives. Identification of criteria can proceed in a series of informal 
and formal discussions attended by key decision makers. A formal meeting of all key 
personnel should be held to review and rank design criteria. This kind of formal 
review and documented ranking of criteria can eliminate the need to second-guess 
project managers on what it is they really want the system and its human component 
to achieve. Additionally, the list of priorities resulting from this discussion will later 
provide analysts with a basis for choosing appropriate outcome measures. Perhaps 
more important than any of these justifications is the sense of working together 
toward a common goal that will evolve from the group discussion of design criteria. 

One caveat to human factors analysts: It is important to remain flexible about 
any ranking of design criteria, especially if the human factors analysis commences at 
an early stage in the system life cycle. Crucial criteria are likely to emerge at later 
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stages, requiring major retrofitting of the analysis. Therefore, a ranking of design 
standards should not be considered "frozen" at earlv stages in system development. 

SUPPORT FROM PROJECT MANAGEMENT 

Project management's responsibility during this orientation phase is to ensure 

that the following kinds of support are provided to the human factors analysis team: 

o assistance in scheduling and coordinating observation 
sessions and briefings 

o provision of staff time for briefings 

o delivery of all available documentation 

o identification of all key decision-makers 

o scheduling and coordination of formal discussion of criteria 

With this support, human factors analysts can proceed quickly toward a conceptual 

understanding of the project and develop a sound basis for applied analysis. 
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CONDUCTING AN APPLIED HUMAN FACTORS ANALYSIS 


OVERVIEW 

In order to be as systematic as possible in determining human requirements and 
in formulating empirically-based recommendations, the human factors analysis 
proceeds; applied evaluation occurs within the identified stage of project 
development. Specific areas for analysis depend on the nature of the project. An 
appropriate combination of human factors tools io used to assess the human factors 
benefits of proposed designs. If the system will go through several iterations or 
releases prior to final implementation, cycles of human factors analysis and review 
continue until a final design is accepted. 

SELECTING AREAS FOR ANALYSIS 

In the sections that follow, major system components requiring human factors 
consideration are identified and discussed. Some of the considerations are based on 
the HFG experiences with MPT and ERBS. The MPT project focused primarily on 
software and documentation issues (Van Balen & Mitchell, 1983), while the ERBS 
MOR analysis was concerned with workstation design (Stewart et al., 1982). The 
other areas— job design, staffing, training, and systems evaluation—are included to 
suggest important areas where human factors analysis can improve system 
performance. Additional areas for analysis can be identified by consulting standard 
references (e.g., DeGreene, 1970a; McCormick <5c Sanders, 1982; Meister, 1971). 

Hardware 

Consideration of the human body, its structure and mechanical functions is 
central to hardware selection and design. This fit of the machine to the capabilities 
of the user increases operator performance, safety, and machine reliability (Van Cott 
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<Sc Kinkade, 1972). The use of reliable anthropometric data (Diffrient, Tilley, & 
Bardagjy, 1981; Mitchell, Stewart, Bocast, Sc Murphy, 19821 permits the designer to 
include adjustable features or set the standards to accomodate the majority (95%) of 
human operators. 

Another area of importance in hardware design is the selection of appropriate 
interaction techniques. There is a large volume of data on hardware components, 
e.g., visual display terminals (VDTs) and alphanumeric keyboards. Guidelines on 
these have become fairly standard. At greater variance are the findings on other 
interaction techniques, e.g., mouse, joystick, and light pen; the resulting guidelines 
are often task dependent. A survey of current recommendations is required to 
support an enlightened choice of hardware. Mitchell et al. (1982) synthesize current 
research findings and relate them to Goddard applications. 

Because hardware procurement occurs early in system development at Goddard, 
it is crucial to have user-oriented guidelines for engineers to consult at this stage. In 
the case of the MPT and ERBS MOR human factors analyses, significant hardware 
was already purchased and thus imposed serious constraints. 

Software 

Issues concerning the human-computer interface are at the forefront of 
computer research. Technology is advancing faster than the human can adapt. Many 
activities in Goddard command and control rooms revolve around operator 
interaction with a computer. In order that computer systems be readily accepted 
and optimally implemented, software designers must consider the user. A partial 
listing of areas to be included for human factors analysis include the following (Engel 
Sc Grand*, 1975; Foley Sc Van Dam, 1982; Mitchell et al., 1982; Ramsey Sc Atwood, 
1979; Smith, 1981): 
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o human-computer dialogue (dialogue types, coding, language 
syntax) 

o cognitive models of the operator (problem-solving 

techniques of users, operator analysis of information 
displays) 

o display screen density and configuration (information 

overload problems, formatting data) 

o fatigue, stress, low productivity, error rate 

o use of graphics, color 

o response time, terminal capabilities 

Human factors analysts can provide recommendations that promote the 
development of an easily interpreted, friendly dialogue. For example, work on the 
MPT software system emphasized designing display frames that were uncluttered, 
consistent in format, and meaningful. 

Documentation 

Preparation of concise, easy to follow operator instructions is a necessity. It is 
through written manuals that design engineers guide the user to successful and 
optimal use of the system. Therefore, it is essential that operations and procedures 
be clearly presented. Inefficient system operation results from failure to provide 
adequate user support in manuals used for operations and maintenance (Damodoran, 
1981; McCormick & Sanders, 1982; Rigney, 1970). 

Human factors analysis provides data on the level of technical information 
needed by users to operate the system effectively. This data, along with knowledge 
of the minimal educational level of the user, guides the designer in selecting the 
appropriate level of vocabulary. For example, preliminary information on MPT 
operations indicated that several operators would be high school graduates. 
Correspondingly, the software engineers designed a user’s manual free of 
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complicated technical jargon. The criteria used by human factors analysts in 
evaluating the manual includes 
o continuity 
o clarity of thought 
o avoidance of jargon or technical words 
o logical presentation of sequence of action 
o adequate number and type of illustrations, cherts 
o adequate spacing, especially in procedures section 
o brevity, yet inclusiveness 
o concentration on hows rather than whys 

On a related topic, Bailey (1982) suggests the use of performance aids, either 
devices or documents to aid the user. HF analysts suggested the use of small durable 
cards to remind the operator of the sequence of actions required for MPT. Attempts 
to facilitate the operator’s understanding and mastery of the system through user- 
oriented manuals and performance aids will help reduce problems in the 
implementation phase. 

Workstation Design 

Inattention to anthropometric and psychological considerations in workstation 
design leads not only to user discomfort, but also to unsafe and unhealthy conditions, 
producing physical and psychological stress (Cakir, Hart, & Stewart, 1980). Human 
factors analysis of workstation design and implementation of the resulting 
recommendations can increase morale and motivation, while reducing stress and 
fatigue (Mitchell et al., 1982; Stewart et al., 1982). The ensuing benefits to 
performance and job satisfaction more than offset the costs of the analysis. 

As detailed in Mitchell et al., (1982), command and control workstation design 
encompasses pre-design considerations, physical layout, equipment design, 
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communication systems, command panel displays, command panel controls, and 
command panel layout. In the case of the ERBS MOR human factors analysis, 
however, the phrase "workstation design" referred to three areas designated by the 
project: physical layout, environmental issues, and component arrangement (Stewart 
et al., 1982). The point here is that the broad nature of workstation design requires 
that it be defined in specific project terms^ In the case of MPT, with users located 
at distant sites, workstation design was not a major Goddard issue, but it was 
considered in collecting survey data that might be useful to system planners at 
Goddard (Van Balen 4c Mitchell, 1983). Whatever the project, it is crucial to define 
the areas for workstation analysis in terms that are mutually acceptable to the 
project and the human factors team. Recommendations that follow, on conducting 
analyses of physical layout, environmental issues, and component arrangement, are 
based on the ERBS MOR experience; guidelines on additional workstation design 
issues can be found in McCormick and Sanders (1982) and other standard references. 

Physical layout. The configuration of equipment deserves close attention 
because of its heavy impact on users. Layout determines patterns of activity within 
the work place; it places constraints on what each seated operator can see, 
determining patterns of person-to-person interaction and patterns of human-machine 
interaction. Physical layout affects job satisfaction, either increasing morale and 
motivation or increasing frustration and annoyance, 

A summary of existing guidelines on aspects of physical layout is provided by 
Mitchell et al. (1982). Areas requiring project-specific application of these 
guidelines, depending on staffing levels and equipment requirements, include physical 
accessibility, visual access, and circulation. Human factors principles used to guide 
an evaluation of alternative physical layouts include the following: 
o Person-to-person interaction should be facilitated. 
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o Physical and visual access to all equipment, controls, and 
displays should be provided. 

o Equipment should be easily maintainable. 

o Traffic flow within and through the work environment 
should be smooth and safe. 

These principles can be relied on as a basis for the development of human 
factors criteria, and they provide a context for conducting project-specific 
analysis. The purpose of such analysis is to achieve the optimal configuration of 
equipment within the constraints imposed by limited resources and requirements for 
maintenance. The ideal configuration is the one which best fulfills human factors 
criteria such as ease of human interaction, ease of human-machine interaction, ease 
of maintenance, and ease of traffic flow (Stewart et al., 1982). 

Appropriate human factors tools are used in determining the optimal 

configuration. Because of severe time constraints, the human factors analysis of the 

<■* 

EKBS MOR workstation design relied almost entirely upon published guidelines and 
observations at Goddard, including informal interviews and discussions. Time 
allowed only non-experimental manipulation of paper mockups, rather than any wider 
ranging simulation of alternative configurations. 

If adequate time can be provided, simulations with different physical layouts 
should be conducted to assess the effect of layout on performance, motivation, levels 
of stress, and job satisfaction. The results of task analysis and link analysis provide a 
framework for the development of various simulated layouts. Computerized 
simulation of physical layouts, as described by Jones, Jonsen, and Van (1982) allows 
researchers to manipulate operating parameters and compare ’’many alternative 
designs...at minimal expense” (p. 40). 

With the capabilities projected for the Goddard Human Engineering Laboratory, 
researchers will be able to employ such techniques. Complete specification of the 
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optimal physical layout can also benefit from formal operator surveys and non- 
expert ental tradeoffs analysis. Converging results from all analyses can then be 
offered to support human factors recommendations on physical layout in Goddard 
settings and other user locations. 

Environmental Issues . In addition to the physical layout of equipment, other 
aspects of the work environment directly or indirectly affect job satisfaction and 
performance. Physical environmental issues include lighting and glare, noise, 
temperature, air quality, furniture, and ambience. Although envrionmental ’issues 
will very from project to project and be of more concern to some than to others, the 
essential purpose of the human factors analysis in this broad area is to humanize the 
environment in order to improve working conditions and to enhance performance 
(Stewart et al., 1982). Additionally, consideration of the work environment is 
intended to support an organization’s image, convey a sense of membership and 
importance to users, support normal environmental conditions, and assist users in 
learning about the workplace (Bailey, 1982; Mitchell et al., 1982). 

A systematic approach to a study of project-specific environmental issues 
requires experimentation with specified levels of environmental variables. Although 
numerous combinations of variables are possible, it is probably most worthwhile to 
limit any one experiment to five or fewer experimental conditions in order to ensure 
interpretability of results. An empirical evaluation of noise effects, for example, 
might compare results at extremes and at levels recommended in the guidelines. 
Another empirical study might isolate a particular variable varying its levels, while 
holding other environmental variables constant. 

Recommendations for ergonomically designed furniture can be made on the 
basis of existing guidelines. Attention to ambience or the atmosphere of the 
workplace should focus on providing coordinated, pleasant colors; visual relief from 
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controls and displays; a clean, odor-free environment; and necessary facilities as 
required by human needs and comfort (Mitchell et al., 1982). Direct experimentation 
on the effects of ambience and furniture on performance are not particularly 
necessary, since these effects are well known, but such experimentation might serve 
to document the role of these variables in Goddard settings. 

Although the effects of some environmental variables are well known, their 
effects when combined are less well understood. It is known, however, that 
environmental load can be a source of stress to the operator and that, under stress, 
an operator is likely to overlook important information on system malfunctions 
(Landy <5c Trumbo, 1980). 

Social-psychological environmental issues include the effects of shiftwork and 
group dynamics in multiperson work situations as well as the need for privacy and 
role definition (Mitchell et al., 1982). Systematic investigation of these issues 
requires both creative experimentation and applied analysis, including observation, 
formal attitude and satisfaction surveys, and interviews. Project-specific physical 
and social-psychological environmental issues should be considered in the interest of 
enhancing job satisfaction, morale, motivation, and performance. 

System Component Arrangement . Research in Goddard settings is needed to 
formulate guidelines on the optimal arrangement of components such as KCRTs, 
monitors, and communications panels. The issue of rack-mounting versus 
adjustibility of terminals is of primary importance because rack-mounting imposes 
severe constraints on what can be done to meet human requirements (Stewart et al., 
1982). If rack-mounting of components continues, empirical evaluation is needed to 
ascertain the relative benefits and limitations of fixed and adjustible components. 
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Current human factors principles of arrangement are applicable when it is 

possible to determine task-activity parameters such as frequency, function, and 

» 

sequence (McCormick & Sanders, 1982): 

Where there are common sequences, or at least frequent 
relationships, in the use of displays, controls, or other 
components, the layout usually should be such as to facilitate 
the sequential process— as in hand movements, eye movements, 
etc. Where there are no fixed or common sequences, the 
components should be grouped on the basis of function, (p. 351) 

If an existing system is being studied for modification, a systematic approach to 

component arrangement entails the use of a variety of techniques such as filming, 

observation, recordings of eye movements, and interviews with operational personnel 

(McCormick <5c Sanders, 1982). If a new system is being developed, activity 

parameters must be inferred from technical documentation and verified to the 

extent possible in discussions with project planners. 

In the case of the ERBS MOR project, it was not possible to conduct a task 

analysis or link analysis to document human interactions or interrelationships 

between operators and physical components. To develop a rationale for component 

arrangement, analysts relied on human factors principles, their own observations in 

command and control environments, briefings by project planners, and technical 

documentation. The proposed component arrangement was then evaluated on the 

basis of human factors criteria, resulting in four recommendations (Stewart et al., 

1982): 

o The operator should be seated between a KCRT and a 
monitor to provide visual and physical access to job- 
related controls and displays. 

o The preferred movement sequence towards a communi- 
cations panel is left-to-right, in agreement with population 
stereotypes. 

o To prevent accidental activation of keyboards, the 
operator should not reach across a keyboard to access a 
communications panel. 
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o Monitors should be placed adjacent to communications 
panels in order to provide work space along the table top; 
if a monitor is placed between KCRTs, keyboards will 
occupy the work space. 

Applied evaluation of alternative component arrangements is suggested to test 
their effects in project-specific settings. 

Job Design 

With the increasing automation of real-time support systems, creative 
approaches to job design are required to offset the problems noted by Mitchell 
(1981): decreased operator ability to detect anomalous events as time spent in 
monitoring increases; risk of ineffectiveness when response is required; and extensive 
inactivity, resulting in operator boredom and degraded performance. In discussing 
the implications of future technologies such as fully automated control systems, 
Griffin (1982) foresees operator alienation, loss of identity, and loss of any sense of 
responsibility or accomplishment. Given these negative implications of automation, 
any organization should consider job redesign and enrichment before making 
decisions on allocation of functions to people and other system components (Cascio, 
1978; Landy & Trumbo, 1980). 

Prior to planning for job enrichment, studies are needed to identify operative 
motivational patterns. Low motivational levels are associated with costly levels of 
turnover, absenteeism, and degraded performance (Bailey, 1982). However, users 
who are motivated by internal values will usually perform well if their assigned work 
affords them autonomy, responsibility, and adequate feedback (Bailey, 1982; 
McCormick & Sanders, 1982). In operational situations where external motivators, 
such as opportunities to socialize, have replaced internal motivators, job enrichment 
to increase meaningfulness of work and sense of worth may be received less than 
enthusiastically. Job enrichment may fail if internal motivating influences are not 
designed into the system (Bailey, 1982; Griffin, 1982; Hackman & Oldham, 1980). 
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Effective job design and redesign involve the allocation of system tasks in such 
a wa*y as to increase the probability of internal motivation. Individual differences in 
knowledge and skill, strength of the need for personal growth, and general job 
satisfaction moderate the success of the job enrichment approach (Hackman 6c 
Oldham, 1980). Although monotonous tasks can be allocated to machines and 
periodic rest breaks can be provided (Bailey, 1982), the human problems of boredom 
and fatigue in the supervisory control situation remain to be addressed. Mitchell 
(1981) suggests that task consolidation, use of simulation exercises, and creative 
construction of the human-machine interface are ways to increase interest and 
productivity while decreasing boredom and workload. Approaches to physical and 
mental workload assessment are discussed in detail by Kantowitz (1982) and Moray 
(1982). 

Strategies of job design are based on diagnosis of the work system (Hackman 6c 
Oldham, 1980). Such strategies attempt to combine system tasks, other activities, 
rest periods, and interface designs to produce high levels of motivation, job 
satisfaction, and performance. Specific diagnostic techniques include observation, 
interviews, informal discussion, and questionnaires such as the Job Diagnostic Survey 
(Griffin, 1982; Hackman 6c Oldham, 1980). Approaches to job design are suggested by 
the job characteristics model (Hackman 6c Oldham, 1980), the Herzberg (1968) job 
enrichment model, the sociotechnical systems model (Davis 6c Trist, 1974), and the 
social information processing framework (Salancik 6c Pfeffer, 1978). A cognitive 
approach to an understanding of work motivation is represented by Vroom's (1964) 
valence/instrumentality /expectancy model. Empirical studies should be based on an 
integrated theoretical framework. 

For work groups such as Goddard's multiperson crews, successful job design 
requires that consideration be given to social systems, group processes, and the total 
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organizational system; implementation and evaluation of changes in job design 
require careful planning to minimize resistance to change and other obstacles to 
success (Cascio, 1978; Griffin, 1982). Although job design was not designated for 
human factors analysis by the MPT or ERBS MOR projects, the human implications 
of automation suggest that this area should be given a high priority. 

Staffing 

A systematic approach to staffing requires qualitative and quantitative 
information about the people needed to operate and supervise a system. Sources of 
information include technical documentation and task analysis. A study of staffing 
requirements produces documents describing positions, manpower requirements, 
selections tests, and training requirements to be used in developing an integrated 
approach to personnel selection (Chapanis, 1970). 

If attention is paid to evolving personnel requirements from the earliest stages 
of system planning, the information gained can contribute to a high level of human- 
machine compatibility. Operational procedures can also be designed in accordance 
with the required physical characteristics, educational levels, skills, and.personality 
traits that have been identified in staffing studies. Such studies, also make it possible 
to plan for the long-term use of human resources (Chapanis, 1970; Huchingson, 1981; 
Schneider, 1976), 

One implication of the staffing literature is that faulty system design results if 
ongoing attention is not paid to human needs. Maximum system performance will not 
result if system design is incompatible with human capabilities and limitations. 
Staffing studies in Goddard settings could aid in achieving higher-than-present levels 
of compatiblity among system components and reduce the kind of ambiguity 
experienced in regard to staffing levels in the ERBS MOR (Stewart et al., 1982). A 
major goal of staffing at Goddard should be to avoid retrofitting of people to 
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equipment and procedures by planning new systems with a focus on the human 
component. Staffing studies could also contribute to the efficient use of personnel. 

Training 

Training has a direct relationship to staffing; the better the selection 
procedures, the more likely the person will be to possess the skills and knowledge 
necessary to perform a job. Therefore, less training is likely to be required. The 
goals of training programs are to have the employee acquire new skills, improve 
problem-solving and decision-making techniques, and develop the motivation for good 
performance (Wexley & Latham, 1981; Goldstein & Buxton, 1982). 

Information obtained from a systematic task analysis forms the basis for the 
content of the training program. Wexley and Latham (1981) provide a detailed 
explanation of five different task analysis procedures for task identification: 
Stimulus-Response-Feedback, Time Sampling, Linear Sequencing, Critical Incident 
Technique, and Job Inventories. Specifically, all these procedures identify the overt 
behavior involved in performing the job. Use of this information ensures a training 
program that includes all system functions, subsequent user actions, and adequate 
evaluation of training effectiveness* 

Martin (1973) further suggests the need for multi-media training techniques. In 
the case of MPT, software developers became aware of the advantage of videotaping 
the main training sessions. These tapes will be sent to the remote sites 
implementing MPT, to be used as training aids locally. 

Analysis of training methods should begin immediately after the critical design 
review. Using the data from a task analysis, the HF analyst can determine whether 
the procedures followed in the training session allow the operator to develop the 
correct conceptual model of the system. Tests on the material to be mastered, 
questionnaires, and interviews are useful measures of training effectiveness. 
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Systems Evaluation 


Within the context of system development, evaluation is necessary to verify 
that system components perform the functions for which they are designed 
(McCormick & Sanders, 1982). Using the continuing feedback from experimental 
testing of individual components, systems evaluation involves the "ongoing human 
assessment of systems performance. ..conducted in the context of operationally 
defined standards of systems performance in relation to available resources in a 
changing systems environment" (Sackman, 1970, p. 152), Planning for total systems 
evaluation should occur in the earliest stages of system development in order to 
ensure that the ultimate design allows for the occurrence of unexpected events, 
human error, environmental changes, and modifications to the system (Sackman, 
1970). Personnel considerations play a central role within a framework of evaluation 
and management regulation. 

Systems evaluation in Goddard settings needs to include personnel at all levels 
in order to provide accurate feedback as the system evolves. If total system 
performance is to be improved, test and evaluation of only hardware and software 
components will fall short of providing complete feedback. The NASA manned 
spaceflight program is an example of an integrated approach to human-machine test 
and evaluation, with data collection and analysis occurring at all stages of project 
development (Sackman, 1970). 

Evaluation techniques available to the human factors analyst include the 
following (Huchingson, 1982): 

o expert or user opinion surveys 
o human engineering checklists 
o observation in operational settings 
o examination of reports on non-routine events 
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o modelling and simulation techniques 
o experimental methods 

Evaluative procedures often suffer from design flaws in three areas: subjects, 
criteria, and experimental procedures (McCormick <5c Sanders, 1982). However, the 
corrective feedback produced by well-designed human factors evaluations can result 
in a higher level of compatiblity among people, machines, environment, and 
procedures, creating conditions necessary for improved performance. 

SELECTING HUMAN FACTORS TOOLS 

Once an area has been identified for analysis, the next step is to select a 
technique or combination of techniques that will provide the necessary data. 
Problems of methodology and research design, beyond the scope of this document, 
are discussed in detail by such authorities as Cook and Campbell (1979), Kerlinger 
(1973), McCormick and Sanders (1982), Parsons (1972), and Plutchik (1983). Various 
human factors tools are described in the sections that follow, providing a sample of 
some commonly used human factors methods. 

Literature Reviews 

Existing guidelines in the human factors literature provide analysts with a 
foundation for conducting an analysis and making recommendations on specific 
Goddard projects. Current guidelines are summarized and synthesized by Mitchell et 
al. (1982). Additionally, analysts should consult any relevant sources in the literature 
for guidance in designing their own studies. A literature review will also reveal 
patterns of agreement or conflict in the results of empirical studies and assist 
efforts to identify human factors issues. An attempt to define human requirements 
will benefit from a review of the literature. When quantitative data is lacking, it 
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may be necessary to extrapolate from research performed in a similar setting. A 
literature review will locate appropriate research findings for extrapolation. 

Task Analysis 

Most human factors analyses include a task analysis. Data derived from this 
exercise form the basis for determining system specifications, level and number of 
staff, design of training programs, possible desigr flaws, and the level of technical 
information required for successful operator performance (NUREG 0700, 1981). 
Because of its universal applicability, the task analysis should be performed as early 
as possible in system development. When entering a project, the HF analyst should 
ask whether a task analysis has been performed. If not, one should be conducted. 

Basically, the procedure is to define system functions and then to analyze and 
describe progressively simpler tasks and subtasks (Meister, 1973). Task analysis 
establishes the behavioral aspects of the system including the sequence of actions. 
McCormick (1979), Anacapa Sciences, (1981), and Meister (1973) present detailed 
information on the steps to follow in a task analysis. Rappold (1982) and Stewart, 
Crowder, and Mitchell (1983) offer examples of task analyses related to the Goddard 
environment. 

Link Analysis 

Another technique used to determine optimal interaction of humans and 
machines is link analysis. It is primarily used to determine the optimal layout of 
people and machines in a system. Links are identified between human/machine, 
human/human, and machine/machine and rated on criteria such as importance or 
frequency. Steps to follow in conducting a link analysis are included in Anacapa 
Sciences (1981), Huchingson, (1981), and Mitchell et al. (1982). Analysts should 
incorporate a link analysis when their task includes workstation design, especially 
component arrangement. 
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Ratings by Experts 

In some cases, design decisions cannot be guided by published research results 
because no research has been conducted on the problem under consideration. 
Although it may be desirable to conduct empirical studies on the specific problem in 
question, lack of time may constrain the human factors analysis to non-empirical 
methods. On other occasions, a non-empirical approach is required by the nature of 
the problem, e.g., the need to rank design criteria, design for ease of maintenance, 
or determine staffing requirements. In these instances, decision making can be 
guided by the systematic application of expert judgment. 

A popular method of soliciting and organizing collective opinion is the Delphi 
technique (Cascio, 1978; Huchingson, 1981). In this process, ratings are anonymously 
collected from individuals knowledgeable in their fields, summarized, and presented 
to these same experts for a second ranking. This procedure continues until a 
consensus appears in the rankings, assuring a more accurate decision than would be 
obtained from a single person or group face-to-face decision making. 

At Goddard, such sessions should include system engineers, project managers, 
and human factors analysts. This participation in the rating process is likely to 
produce a high level of commitment to the final decision. 

Non-Experimental Simulation 

When time constraints do not permit empirical evaluation of different designs, 
physical simulation using mockups can help analysts visualize alternatives and assess 
tradeoffs. The fidelity of a simulation to a particular piece of equipment or real 
environment may range from the very abstract to the ’’real" thing. The degree of 
fidelity required is open to question but probably depends partly on the level of detail 
needed for decision making. 
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Non-experimental manipulation of paper mockups provided decision makers 
with a basis for selecting workable designs for the ERBS MOR and permitted a rapid 
assessment of each alternative’s benefits and limitations (Stewart et al., 1982). In 
order to offset Individual subjective judgments, this approach is best employed by 
analysts working together. It also lends itself well to use in project planning sessions 
as a means of achieving group consensus. 

Surveys and Interviews 

Data on user variables, such as attitude and job satisfaction, is collected by 
means of sample surveys and formal interviews (Her linger, 1973). Rigorous sampling, 
questionnaire construction, and validation are essential if results will be analyzed for 
statistical significance. Application of these techniques in Goddard settings is 
recommended, for example, to determine motivational patterns prior to designing 
jobs for supervisory controllers. 

A good way to gather information about the intended user of a planned system 
is to conduct an informal survey of those currently in an antecedent operating 
system or those for whom the system is being specifically designed. This survey, in 
the form of a questionnaire, gathers information on the operating environment. For 
example, surxey questions might cover the following areas: lighting, sound, 

component flexibility, ambience, personnel, supervisory style, task load, and 
operating procedures. A sample survey can be found in Van Balen and Mitchell 
(1983). 

Surveys should be individually styled according to the intended audience and 
type of information sought. Information obtained from the questionnaires is helpful 
as a decision-making aid in the design process. References for help in conducting 
surveys include Babbie (1973), Kish (1965), and Stopher and Meyburg (1979). 
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Empirical Evaluation 

The emphasis in human-machine system experiments is on the controlled 
manipulation of specified variables to test one or more hypotheses (Parsons, 1072). 
If levels of variables are not directly controlled, fallacious interpretations of results 
are likely (Kerlinger, 1973). One function of the proposed Goddard Human 
Engineering Laboratory is the performance of human-machine experiments. 

Simulation . Empirical, simulation-based evaluation of alternative workstation 
designs, for example, requires at least two possible configurations and data 
collection on such measures as performance, stress, fatigue, and job satisfaction 
from experimental and control subjects. Issues in simulation research, including 
levels of fidelity and methods of measqring human performance, must be addressed 
and solutions applied consistently to ensure generaliaability of results from study to 
study and setting to setting. Guidelines on the construction and experimental use of 
mockups are provided by Mitchell et al. (1982). 

Studies of Group Processes . Empirical evaluation can occur in field 
experiments conducted in operational settings. This approach is particularly suited 
to the study of small group dynamics but requires the experimenter to control 
sometimes uncontrollable variables (Cook <5c Campbell, 1979; Kerlinger, 1973). The 
random assignment of subjects would, in itself, present a challenge to researchers in 
Goddard settings. If the difficulties of field experimentation can be overcome, 
valuable data can be collected on optimal work-rest cycles, social systems, and job 
design (Kahn, 1974; Parsons, 1972; Shaw, 1976), 

Modelling 

As a diagnostic tool, modelling overlaps with simulation techniques yet is 
distinctive in its mathematical approach. Modelling, a quantitative design method of 
representing the human-machine interface, allows engineers to predict design 
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choices. A preliminary task analysis aids in defining the parameters of the model. 
The Mitchell et al. (1982) guidelines provide a synopsis of possible modelling 
techniques to incorporate in system design at Goddard. Pew and Baron (1982) offer 
an interesting comparison of psychologically based models, such as network and 
information processing models, and several control theoretic approaches to modelling 
human behavior. In order to use modelling techniques effectively, one must have a 
strong background in mathematics and experience in developing models. 

Tradeoffs Analysis 

A systematic assessment of the benefits and limitations of alternative designs 
can occur only within the context of a well-defined set of design criteria. Without 
explicit, ranked criteria, such an assessment will be haphazard and invalid. If 
adequate time is not provided for application of the appropriate human factors tools 
to the designated areas for analysis, tradeoffs associated with alternatives must be 
assessed entirely on the basis of recommended guidelines and human factors 
expertise. Working down through the ranked criteria, analysts must judge the degree 
to which each design fulfills each criterion. This can be a time-consuming process, 
but it provides a rational basis for making recommendations to the project (Stewart 
et al., 1982). 

When sufficient time has been permitted for data collection and analysis, 
benefits and limitations of particular designs can be assessed and recommendations 
justified with quantitative support. It may, for example, be possible to compare the 
relative costs of different configurations in terms of error rates, stress levels, and 
effects on motivation. A systematic appraisal of design benefits might also be 
supported by appropriately weighted performance and job satisfaction data. A 
complete tradeoffs analysis, providing a balanced assessment of benefits and 
limitations, is a necessary step if the project is considering alternative designs. 
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DOCUMENTING THE ANALYSIS 

Once the human factors analysts have become oriented to the project and have 
examined the design from a user’s perspective, they are ready to formulate 
guidelines to present to the project for consideration. 

Record Keeping 

In the early stages of development, analysts may be given specific tasks such as 
recommending the best selection of color combinations to use on CRT displays. A 
written record of all such tasks and recommendations should be kept. A chronology 
of human factors activities is especially useful as a reference. 

Reports 

A written report is needed where analysis covers a large area. For example, 
response to a design review or the presentation of specific recommendations for 
design issues under consideration require a concise written report. These interim 
reports are valuable sources of communication with the project;- they state the 
human factors recommendations based on documented research or expert opinion and 
prompt a response from the project concerning these recommendations. In the case 
of MPT, a written report plus red-inked suggestions written in a user's manual were 
used to document needed changes in the manual. A report that generates 
appropriate questions concerning design issues raised during a design review also 
initiates further interaction with the project. For example, the human factors 
analysts can assist the design team in responding to Review Item Dispositions (RIDS) 
raised during a formal design review. Immediate follow-up or response to all reports 
is recommended. At the conclusion of a contract, a final report is prepared 
documenting all human factors analyses and recommendations. It is distributed to 
the project and members of the Human Factors Group. 
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Presentations 


Upon completion of the human factors analysis, it is possible that the analyst 
will be asked to give a presentation. Ideally, this presentation should not last more 
than 40 minutes, depending on the scope of the topic. Viewgraphs should be prepared 
and a corresponding handout distributed to those attending the presentation. This 
procedure was used sucessfully in summarizing the process of design evolution and 
presenting major recommendations of the ERBS MOR workstation design analysis. 


MANAGEMENT SUPPORT 

During the performance of a human factors analysis, there is a continuing need 
for management support in the following areas: 

o provision of adequate facilities and equipment as required 
by analytical procedures 

o scheduling of personnel to meet the requirements of 
experiments and field studies 

o liaison between the human factors team and the project 

o execution of verbal assurances concerning delivery of 
required information and documentation 

This support assures the timely completion of the analysis which, in most cases, 
requires extensive coordination and cooperation among all those concerned. 
Management's positive attitude, conveyed through its facilitation of the analysis, 
contributes to the conditions necessary for the general acceptance and 
implementation of ensuing human factors recommendations. 
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COORDINATING THE ANALYSIS: 

MAJOR STAGES OF SYSTEMS DEVELOPMENT 

OVERVIEW 

To ensure maximum compatibility of physical components and human operators, 
human factors analysis is required during the major stages of systems development 
(Meister, 1982)* However, human factors support is not always requested or 
incorporated in the early phases of system concept generation. Human factors 
support is often requested only at an advanced design stage. For this reason, 
analysts need to determine what engineering stage is in progress when they are 
introduced to a project, become familiar with the project's background and 
operations, and proceed to conduct an appropriate analysis. The point at which a 
human factors analysis is introduced determines, in part, the extent to which human 
factors recommendations can be effectively incorporated to produce high levels of 
compatibility among system components, e.g., hardware, software, personnel, and 
environment. 

SYSTEMS DEVELOPMENT 

An overview of the engineering stages of system development is given by 
DeGreene (1970a). As illustrated by Figure 1, the engineering stages in systems 
development establish a framework for human factors analysis. Beginning in the 
conceptual stage, refinement of system requirements moves from the general to the 
specific. From the conceptual or planning stage, systems development proceeds 
through definition, design and production, and operational stages (DeGreene, 
1970a). The concluding phase of the definition stage overlaps with the beginning of 
the design and production stage, as indicated by the parallel section of the diagram 
in Figure 1. This overlap occurs because the iterative design process contributes to 
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Figure 1 : Human Factors Impact on System Life Cycle 

(adapted from De Greene, 1970) 
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refinement of system requirements and because further definition necessitates 
design readjustments. Evaluations conducted during the operational stage contribute 
to the development of enhancements to the current system. Systems development 
proceeds in life-cycles, with concepts for a second generation system evolving from 
experience with the operational system, as indicated by Figure 1. 

In the Goddard environment, engineering stages are described by the phrases 

incorporated into Figure 2: Study Phase; Requirements Definition; Design, including 

Preliminary Design Review (PDR) and Critical Design Review (CDR); Hardware 

Requirements; Implementation; Test; and Operations. This breakdown of stages in 

systems development can be considered as an alternative to and further elaboration 

on De Greene's terminology: 

o Conceptual or Planning Stage = Study Phase 

o Definition Stage = Requirements Definition 

o Design and Production Stage = Design (PDR and CDR) + 

Hardware Requirements + Implementation + Test 

o Operational Stage = Operations 

The crucial point made by Figure 2 is that an early introduction of human factors 
analysis is necessary to ensure the effective incorporation of recommendations 
emerging from the analysis. The more complete the project is when human factors 
analysis begins, the less likely it is that effective use can be made of input from the 
analysis (Moe, 1982). 

The following sections, based on DeGreene's (1970a) framework, provide a guide 
to the application of appropriate human factors techniques at each stage of systems 
development. These sections suggest ways to coordinate the human factors analysis 
with the design activities that typically occur during each major engineering stage. 
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CONCEPTUAL OR PLANNING STAGE: ANALYZING SYSTEM REQUIREMENTS 

The decision to design a new system generally results from the identification of 
an existing problem, e.g., a desire to update a current system or to increase 
productivity by integrating new technology. After appropriate analytic field studies 
and comparative research, a preliminary concept of the parameters and functions of 
the system emerges. Requirements are then broadly defined for hardware, 
performance, personnel, and training. Constraints, criteria, interfaces, and 
subsystems are also specified. 

It is at this point that human factors analysis most effectively aids in 
determining the user requirements tempered by any contingencies or constraints, 
e.g., cost. Progressively, the defined requirements move from preliminary concepts 
to more specific definitions. During this stage, the HF analysts complete the 
identification of subsystems and their relationships and a preliminary analysis of 
behavioral and informational requirements. Appropriate human factors tools include 
literature and documentation review, surveys and interviews, preliminary staffing 
and training studies, and ratings by experts. 

DEFINITION STAGE: ANALYZING JOBS AND ALLOCATING FUNCTIONS 

As planning continues and finer definition of system requirements begins, 
tradeoffs analyses of alternative subsystem configurations become a basis for 
allocating functions to humans and machines. During the definition stage, a 
preliminary determination of organizational structure should occur. At this point, 
general tasks, functions, and jobs can be described as performed by individuals and 
groups. 

If a human factors analysis is introduced during the definition stage, there is a 
good chance that the ultimate system will provide for human requirements. At this 
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point in systems development, human factors analysts evaluate the acceptibility of 
preliminary function allocation by performing task and job analyses. Continuing 
human factors evaluation of alternative subsystem components contributes to the 
resolution of specific design issues such as use of color or choice of interactive 
devices. 

Adequate human engineering of the system also demands studies of staffing and 
training requirements. Preparation of all external documentation, e.g., training 
manuals and user’s manuals, requires analysis, evaluation, and critique of alternative 
formats; criteria of readability and inclusiveness should be applied to all 
documentation. 

Throughout this stage, simulation or modelling of the system, based on 
previously established system requirements, provides feedback to the definition 
process. As human, machine, and environmental requirements are further defined, 
the simulation or model developed during the conceptual stage evolves from a gross 
representation of the system to a detailed facsimile. Results from analyses 
performed during the definition stage become decision aids in design evolution. 

DESIGN AND PRODUCTION STAGE: INTEGRATING SYSTEM COMPONENTS 

With further definition bringing system requirements into clear focus, the 
design and production stage incorporates the results of previously performed task 
analysis and other human engineering studies. This stage includes the presentation of 
preliminary and critical design reviews. Informal working sessions are held to 
consider designs of specific system sub-components. The results of human factors 
analyses should be incorporated and further refined as the design continues to evolve 
in a series of dynamic interactions. The goal at this point in systems development is 
to achieve integration or compatibility of hardware, software, personnel, and work 
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environment. The results of systems test and evaluation provide information 
required to achieve this goal. 

If the physical system already exists when the human factors analysis is 
introduced, it will probably be too late for maximum HF effectiveness in achieving 
full integration of system components. Some retrofitting may be possible to the 
extent that any flexibility remains, although existing equipment will impose 
constraints on what can be done (Stewart et al., 1982). Despite difficulties, human 
factors analysts must attempt to identify all areas of flexibility, conduct their 
analyses, and offer realistic recommendations based on the human factors 
implications of alternative designs. Appropriate human factors tools include 
literature and documentation review, surveys and interviews, simulation using 
mockups, and tradeoffs analysis. 

OPERATIONAL STAGE: EVALUATING AND MAINTAINING THE SYSTEM 

Once the design is operational, with production completed and personnel 
trained, the system is implemented. For the HF analyst, this stage of system 
development allows field evaluations of human performance in the operational 
system and permits the identification of design problems not previously anticipated. 
Any required modifications are then incorporated into the design. User response to 
the system can be evaluated through measures of stress, fatigue, and job 
satisfaction. Human performance data should be collected for purposes of error 
analysis (Shneiderman, 1982). The integration of maintenance procedures should also 
be analyzed at this time. Suggested changes should be evaluated for their potential 
impact on the human-machine interface. 

External documentation, e.g., maintenance and user's manuals, should be 
reevaluated from the user's perspective. Internal documentation of computer 
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software should be reviewed to ensure that future programmers can easily maintain 
and modify the code. The reliability of the system ensures its optimal use and 
acceptance. Human factors considerations should continue to receive attention for 
the life of the system in order to identify areas where enhancements would 
contribute to improved performance and productivity. 



SUMMARY 

At whatever point in system development that human factors analysis is 
introduced, a written contract is required to clarify and formalize the 
responsibilities and commitments of the HF team and the project. Following initial 
contact and contract development, an orientation period is required to familiarize 
analysts with the project. The identification and ranking of human factors criteria 
should occur prior to the initiation of any analysis or evaluative study. 

The human factors analysis proceeds with the application of appropriate HF 
tools to the area or areas designated for analysis in the contract. The success of the 
analysis depends on allowing sufficient time in the design schedule. Documentation 
of the analysis includes thorough record keeping, written reports, and oral 
presentations to appropriate groups. Attention to human factors continues 
throughout the life of the system. 

Ideally, a human factors analysis should begin during the conceptual or planning 
stage of system development when broad system requirements are established. In 
order to achieve the goal of compatibility among system components— hardware, 
software, personnel, and environment— a human factors analysis should commence no 
later than the definition stage. If the design is close to being finalized and system 
production is underway, full implementation of human factors recommendations will 
not be possible. The role of human factors analysis during the operational stage of 
the system life cycle is to evaluate effects on the human component for purposes of 
modification and enhancement. 
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